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(54) Terminal device capable of remote download, download method of loader program in 
terminal device, and storage medium storing loader program 



(57) Memory is divided into a plurality of banks to 
store software which is upgraded one bank at a time. By 
doing so, a memory with the same size as one bank is 
only needed as the temporary storage used when per- 
forming an upgrade. The terminal device only needs a 
memory that is "1+1 /n" times as large as a total software 
when there are n banks, while a conventional terminal 
device needs a memory that is twice as large as the total 



software. Two loader programs are stored in different 
banks as a master loader program used for download 
processing and a backup loader program. On receiving 
a new loader program, one loader program is used to 
write the new loader program over the other loader pro- 
gram so as to upgrade the loader program. The backup 
loader program is activated when the new loader pro- 
gram is to be written over the master loader program. 
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Description 

BACKGROUND OF THE INVENTION 
1 Field of the Invention 

The present invention relates to a terminal device 
in a service system using a cable or wireless communi- 
cation medium, a download method of a loader program 
in the terminal device, and a storage medium storing the 
loader program. 



2. Description of the Prior Art 

In recent years, broadcast service business using 
cable or wireless communication mediums has received 
much attention in industry. In particular, digital satellite 
broadcasting and digital CATV (Community Antenna 
Television System) have captured much of the spotlight 
for their huge potential for development. 

On the other hand, there is a difficulty in mainte- 
nance of terminal devices. The terminal devices referred 
to here are highly intelligent terminals containing various 
types of software modules, so that the maintenance of 
the terminal devices includes bug fixing and specifica- 
tion changes for these software modules. 

Usually, bug fixing and specification changes are 
carried out by upgrading the software modules. Howev- 
er, as more and more households use such terminal de- 
vices, it becomes increasingly difficult for a broadcast 
station to upgrade the software modules. 

In order to uniformly upgrade software modules in 
each terminal device, it is necessary for a host station 
to transmit the new version of the software modules to 
each terminal device via a communication medium. If a 
terminal device is a personal computer-type device 
equipped with a hard disc device and a file system for 
accessing areas on the hard disc device in units of di- 
rectories and files, the software upgrade can be 
achieved by installation. More specifically, the host sta- 
tion first transmits an installer software module and the 
new version of software modules to each terminal de- 
vice. In each terminal device, the installer software mod- 
ule creates a new directory on the hard disc and stores 
the new version (the new version may instead be stored 
in a directory which stored the old version). 

However, in order to be widely distributed at low 
cost, standard terminal devices used for broadcast serv- 
ices are generally composed of a microcomputer sys- 
tem type which has neither a hard disc device nor a file 
system. In the microcomputer system type, software 
modules are directly stored in a memory such as an 
EEPROM (Electrically Erasable and Programmable 
ROM which is capable of electrically erasing and rewrit- 
ing storage contents). Accordingly, it is impossible to ac- 
cess a software module in units of directories and files 
when upgrading the software module. 

In these terminal devices, the software modules 



stored in the EEPROM or the like are upgraded by re- 
mote download. 

In general, download is a process of writing data 
stored in a secondary storage into a primary storage. In 
5 a remote download, the primary storage is a memory in 
each terminal device and the secondary storage is a 
hard disc device in the host station. 

In the remote download process, the host station 
transmits data in the secondary storage to each terminal 
10 device. Each terminal device analyzes the received data 
and performs error detection and other processing, be- 
fore writing it into a free area of the primary storage 
(here, the free area is an area which is not occupied by 
other software modules). 
15 The above process in the terminal device is per- 
formed by a processor executing a loader program 
which is stored in the EEPROM of the terminal device. 

Here, it is not safe for the terminal device to write 
the new version of the software module received from 
20 the host station directly over the old version. If power to 
the terminal device is cut off during the overwriting, both 
the new and old versions in the primary storage will be 
incomplete and inoperable. Thus, it is necessary to save 
a backup copy of the old version in case of power dis- 
25 connection during the overwriting. 

In order to backup the old version of a software 
module, it is necessary to copy all software modules 
stored in the primary storage of the terminal device for 
the following reason. When a new software module has 
30 a memory size larger than its old version, it will be written 
into not only an area occupied by its old version but also 
an area occupied by other software modules. Suppose 
software modules 1-5 which have been written in se- 
quence starting from the first address of the primary 
& storage are to be upgraded. If the new version of soft- 
ware module 1 has a memory size larger than its old 
version, it will be written not only over its old version but 
also over software modules 2 and 3. As a result, soft- 
ware modules 2 and 3 will be erased from the primary 
40 storage. If power to the terminal device is cut off at this 
stage, it may not be possible to restart the terminal de- 
vice. 

In order to avoid malfunctions caused by disrup- 
tions to the power supply during the remote download, 

45 the following two design constraints are given for con- 
ventional microcomputer system-type terminal device. 

The first design constraint is that a terminal device 
should be provided with two memory chips which each 
have a capacity equal to the total size of software mod- 

50 ules stored in the terminal device, one memory chip for 
backup of old software modules and the other memory 
chip for writing new software modules. By doing so, 
even when the power is cut off during the writing of the 
new software modules, the terminal device can be re- 

55 started using the backup copy of the old software mod- 
ules. 

The second design constraint is that the loader pro- 
gram for download is not to be upgraded: 
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Fig. 1 shows an example of a conventional terminal 
device constructed in accordance with the above con- 
straints. In the figure, the terminal device includes a 
main EEPROM 81 as a primary storage which stores 
software modules containing programs and data ; an up- 
grade EEPROM 82, a ROM 83 storing a loader program, 
and a program execution unit 84 for executing the loader 
program. 

When the terminal device is started, the program 
execution unit 84 executes the programs stored in the 
main EEPROM 81 in accordance with a boot program 
stored in a boot ROM. On receiving new software mod- 
ules Irom the host station during the program execution, 
the program execution unit 84 successively stores them 
into the upgrade EEPROM 82. 

On completing the upgrade, the program execution 
unit 84 switches to start the new programs stored in the 
upgrade EEPROM 82. If, on the other hand, the upgrade 
fails, the program execution unit 84 starts the programs 
stored in the main EEPROM 81 again and retries the 
upgrade. 

In order to save backup copies of all software mod- 
ules, each terminal device must be equipped with EEP- 
ROMs which are twice as large as the total size of the 
software modules. Though this is necessary for ensur- 
ing that terminal devices can always be started, it caus- 
es increases in the hardware scale and the production 
cost of each terminal device. The total software size in- 
cluded in a conventional terminal device has to be lim- 
ited in order to suppress production cost, which means 
that advanced software functioning must be sacrificed. 

Also, an extensive process of exchanging a ROM 
is necessary for each conventional terminal device 
when bug fixing and specification changes have to be 
done on the loader program. In such a case, the broad- 
cast company must send its service personnel to each 
customer to exchange the ROM without charge. The la- 
bor cost resulting from such a service places a tremen- 
dous burden on the company. 

SUMMARY OF THE INVENTION 

It is an object of the present invention to provide a 
terminal device which can execute advanced software 
without increasing the production cost. 

It is another object of the present invention to pro- 
vide a terminal device in which it is possible to upgrade 
a loader program. 

The above object can be fulfilled by a terminal de- 
vice that includes: a first memory having n areas which 
are each given a unique bank address, n being an inte- 
ger that is no less than 2, wherein each area is com- 
posed of an occupied area storing at least one software 
module and a free area which is used when a data size 
of the software modules increases as a result of upgrad- 
ing the software modules; a second memory having a 
same memory size as each area; a reception unit for 
receiving transmission data from a host station, wherein 



the transmission data includes a content part and a 
header part, wherein the content part includes at least 
one new software module corresponding to at least one 
software module stored in any of the n areas, and the 
5 header part includes a target bank address specifying 
an area into which the new software modules are to be 
stored, wherein each new software module is new to the 
terminal device, that is, each new software module has 
more recent version information than a corresponding 
io software module stored in any of the n areas; a separa- 
tion unit for separating the header part from the trans- 
mission data and storing the content part which includes 
the new software modules into the second memory; a 
detection unit for detecting the target bank address from 
is the header part; and a write unit for writing the new soft- 
ware modules stored in the second memory into the ar- 
ea specified by the detected target bank address. 

With the stated construction, memory is divided into 
a plurality of areas to store software which is upgraded 
one area at a time. By doing so, a memory with the same 
size as one area is only needed as the temporary stor- 
age' used when performing an upgrade. The terminal de- 
vice only needs a memory that is "1+1/n" times as large 
as the total software when there are n areas, while a 
conventional terminal device needs a memory that is 
twice as large as the total software. 

It is possible to reduce a scale of hardware that can 
withstand errors that occur during software upgrades. 
As a result, advanced software can be installed in the 
terminal device without increasing the production cost. 

Also, it is possible to safely upgrade software mod- 
ules in a short period of time by writing the new software 
modules into an appropriate area without a danger of 
overwriting software modules in other areas. 

Here, among the n areas, a first area and a second 
area rnay respectively store a master loader program 
and a backup loader program, and wherein the write unit 
includes: a first write control unit for writing, when the 
detected target bank address specifies an area other 
than the first area, the new software modules stored in 
the second memory into the area other than the first area 
according to the master loader program in the first area; 
and a second write control unit for writing, when the de- 
tected target bank address specifies the first area, the 
new software modules stored in the second memory into 
the first area according to the backup loader program in 
the second area. 

With the stated construction, two loader programs 
are stored in different areas, so that a loader program 
can be upgraded by writing the new loader program over 
one loader program while executing the other loader 
program. Bug fixing and specification changes for the 
loader program can be conducted easily by upgrading 
the loader program in the above way without exchang- 
ing ROMs that incurs a great labor cost to the broadcast 
company. 

Here, a first area, among the n areas, may store a 
master loader program, wherein the write unit includes: 
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a first write control unit for writing, when the detected 
target bank address specifies an area other than the first 
area, the new software modules stored in the second 
memory into the area other than the first area according 
to the master bader program in the first area; a second s 
write control* unit for writing, when the detected target 
bank address specifies the first area, the new software 
modules stored in the second memory into a second ar- 
ea which is different from the first area according to the 
master loader program in the first area; a monitor unit 10 
for monitoring, after the new software modules are writ- 
ten into the second area, whether the second memory 
stores at least one new software module corresponding 
to at least one software module which was previously 
stored in the second area; and a third write control unit 1$ 
for writing, when the second memory stores the new 
software modules corresponding to the software mod- 
ules which were previously stored in the second area, 
the new software modules stored in the second memory 
into the first area according to a new master loader pro- 20 
gram included in the new software modules written in 
the second area. 

With the stated construction, the loader program 
can be upgraded without using the backup loader pro- 
gram by writing the new software modules for the first 25 . 
area into another area. By using only the master loader 
program, more software modules can be stored in place 
of the backup loader program. 

Here, the content part may include a plurality of new 
software modules, and the header part may include a 30 
plurality of target bank addresses which each specify an 
area into which each new software module in the con- 
tent part is to be stored, wherein the terminal device fur- 
ther includes a third memory having the same memory 
size as each area, and wherein the write. unit includes: 35 
a retrieval unit for retrieving one of the plurality of new 
software modules in the content part from the second 
memory; a first write control unit for writing all software 
modules stored in an area specified by a detected target 
ban k address for the retrieved new software module into 40 
the third memory; a replacement unit for replacing a soft- 
ware module, out of the software modules stored in the 
third memory, which corresponds to the retrieved new 
software module with the retrieved new software mod- 
ule; a second write control unit for writing the software 45 
modules after a replacement by the replacement unit 
from the third memory into the area specified by the de- 
tected target bank address; and a retrieval control unit 
for having the retrieval unit retrieve another new soft- 
ware module, out of the plurality of new software mod- so 
ules, from the second memory after a write by the sec- 
ond write control unit. 

With the stated construction, the terminal device re- 
ceives the new version of software modules to be up- 
graded from the host station and replaces each software ss 
module. As a result, the upgrade processing can be 
completed faster than the upgrade processing per- 
formed by replacing software modules in area units. 



BRIEF DESCRIPTION OF THE DRAWINGS 

These and other objects, advantages and features 
of the invention will become apparent from the following 
description thereof taken in conjunction with the accom- 
panying drawings that illustrate a specific embodiment 
of the invention. In the drawings: 

Fig. 1 shows the construction of a conventional ter- 
minal device; 

Fig. 2 shows the construction of the terminal device 
10 in the remote download system of the first and 
second embodiments; 

Fig. 3A shows the construction of elementary 
streams decoded by the TS decoder 2; 
Fig. 3B shows the construction of a program head- 
er; 

Fig. 4A shows the construction of a software mod- 
ule; 

Fig. 4B shows the construction of a module header; 
Figs. 5A and 5B show which software modules are 
stored in each bank; 

Fig. 6 shows the construction of a private stream of 
the third embodiment; 

Fig. 7 shows the construction of the terminal device 
10 of the third embodiment; 

Fig. 8 is a flowchart showing the kernel processing 
of the first embodiment; 

Fig. 9 is a flowchart showing the loader program 

processing of the first embodiment; 

Fig. 10 is a flowchart showing the loader program 

processing of the second embodiment; 

Fig. 1 1 is a flowchart showing the loader program 

processing of the third embodiment; 

Figs. 1 2A and 1 2B show how bank data for bank n 

is stored into a ROM according to a loader program 

of the first embodiment; 

Figs. 13A-13C show how bank data for bank 1 is 
stored into the ROM according to the loader pro- 
gram of the first embodiment; 
Figs. 14A-14D show how bank data for bank 1 is 
stored into the ROM according to a loader program 
of the second embodiment; 

Figs. 1 5A-1 5D show how each software module for 
a respective bank is stored into the ROM according 
to a loader program of the third embodiment; 
Figs. l6A-16Cshowhoweachsoftwaremodulefor 
a respective bank is stored into the ROM according 
to the loader program of the third embodiment; 
Fig. 17 shows the construction of the terminal de- 
vice 10 of the fourth embodiment; and 
Fig. 18 shows the construction of the terminal de- 
vice 10 of the fifth embodiment. 
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DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

First Embodiment 

The following is an explanation of a terminal device 
of the present invention with reference to the figures. 

Here, a terminal device 10 is provided to each 
household which is a subscriber of a broadcast service 
A. The broadcast service A broadcasts a variety of TV 
programs such as movies, dramas, sports, and educa- 
tional programs via satellite. This broadcast service A 
can provide more channels and a higher picture quality 
than broadcast services that use ground waves. The ter- 
minal device 1 0 is equipped with various intelligent func- 
tions, in addition to a tuner and a decoder for displaying 
the programs on a TV receiver. The intelligent functions 
include display ol weekly and monthly electric program 
guides (EPG), display of headline news, invoicing, on- 
line quizzes, TV shopping, games, and karaoke, with the 
emphasis on user interaction. 

Fig. 2 shows the construction of the terminal device 
10. In the figure, the terminal device 10 includes a CS 
tuner 1 , a TS decoder 2, an AV decoder 3, a download 
RAM 4, a software module group storage unit 5, a proc- 
essor 6, and a boot ROM 7. The device is connected to 
a TV receiver and a video deck in each household. 

When a CS antenna receives a 7t/4QPSK (Quadra- 
ture Phase Shift Keying) -modulated broadcast wave, 
the CS tuner 1 demodulates it and outputs the resulting 
transport packet that conforms to MPEG2 (Moving Pic- 
ture Expert Group 2) Standard to the TS decoder 2. 

The TS decoder 2 separates the transport packet 
into four elementary streams which are a video stream, 
an audio stream, a PCR (Program Clock Reference) 
stream, and a private stream. The video stream, the au- 
dio stream, and the PCR stream which compose a TV 
program are outputted to the AV decoder 3, while the 
private stream which is used for maintenance of the in- 
telligent functions is stored into the download RAM 4. 

Fig. 3A shows the construction of four elementary 
streams. The video stream is composed of a Pi D (Pack- 
et Identification), video data, and a CRC (Cyclic Redun- 
dancy Check Code). The audio stream is composed of 
a PID, audio data, and a CRC. The PCR stream is com- 
posed of a PID, PCR data, and a CRC. The private 
stream is composed of a PID, a program header (Prg- 
Header in Fig. 3A), bank data, and a CRC. Each PID is 
used by the TS decoder 2 for judging whether the ele- 
mentary stream is to be outputted to the AV decoder 3 
or the download RAM 4. 

The bank data is a software module group which is 
transmitted from the broadcast station and which is to 
be stored into the same bank. In the present embodi- 
ment, a bank is a divided area in the memory of the ter- 
minal device. 

One example of the program header included in the 
private stream is shown in Fig. 3B. In the figure, "pro- 



gram name" shows a bank data name, "data size" 
shows a bank data size, "bank number" shows a bank 
address into which the bank data is to be stored, and 
"version information" shows a production date or a most 
5 recent renewal date of the bank data. 

The AV decoder 3 decodes the video and audio 
streams into image signals using the PCR stream and 
outputs the image signals to the TV receiver. 

The download RAM 4 is a SIMM (Single In-Line 
10 Memory Module)-type DRAM (Dynamic RAM) or EEP- 
ROM for storing the private stream transmitted from the 
TS decoder 2. 

The software module group storage unit 5 is com- 
posed of n banks which store a plurality of software mod- 
15 ules (in Fig. 2, the n banks are four banks 1 -4). Each 
bank is an EEPROM chip (hereinafter, EEPROMs 
51 -54) and has a storage capacity about the same as 
the download RAM 4 Software modules stored in the 
software module group storage unit 5 are a plurality of 
20 types of software modules including data and programs 
which have been uniformly modularized. 

The EEPROMs 51-54 are connected to a second 
bus 9. A logical address is assigned to each internal 
storage area in each EEPROM so that the processor 6 
25 can directly access the internal storage areas. Each log- 
ical address is expressed as a combination of a bank 
address which is assigned to each bank and an offset 
address which specifies an internal storage area in each 
bank. 

30 Fig. 5 A shows a memory image of the EEPROMs 
51-54. In the figure, logical addresses 000000 to 
OFFFFF correspond to a bank address 01 , while logical 
addresses 1 00000 to 1 FFFFF correspond to a bank ad- 
dress 02. 

35 Bank 1 stores software modules 1-10, while bank 2 
stores software modules 11-20. The software modules 
are consecutively stored from the top of each bank so 
that a free area is left at the bottom. This free area is 
used when upgrading the software modules in each 

40 bank. For example, when, during an upgrade of soft- 
ware modules 1-10 in bank 1, the new version has a 
larger size than the old version, the new version is writ- 
ten into the area occupied by the old version of software 
modules 1-10 and the free area but not into the area 

45 occupied by software modules 11-20 in bank 2. 

Thus, the software modules in each bank can be 
upgraded without overwriting software modules in the 
next bank by using the free area. 

Fig. 4 A shows an example of a software module for- 

50 mat. 

The software module is composed of a module 
header, an entity unit, and a CRC. 

Fig. 4B shows an example of the module header. 
The module header is composed of "program name", 
55 "data size", "bank number", and "version information". 
"Program name" shows a software module name, "data 
size" shows a software module size, "bank number" 
shows a bank address into which the software module 
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is to be stored, and "version information" shows a pro- 
duction date or a most recent renewal date of the soft- 
ware module. It should be noted that the bank data is 
composed of a plurality of software modules which are 
to be stored in the same bank, each software module 
having the format shown in Fig. 4A. 

In the present embodiment, each software module 
needs to be "relocatable", that is, the software module 
can be executed regardless of where it is stored in the 
software module group storage unit 5. This is because 
it is more desirable for the broadcast company that a 
location of each software module in the software module 
group storage unit 5 be changeable. 

Each software module is categorized either as an 
operating system component or an application program. 
This means that the terminal device 10 has a software 
management construction similar to a standard compu- 
ter in which each application program is operated based 
on the operating system. 

Fig. 5B shows which software modules are stored 
in banks 1 and 2 of the software module group storage 
unit 5. As shown in the figure, the software module group 
storage unit 5 stores a variety of software modules in- 
cluding font data, bitmap data, and graphic data Main 
software modules which make up the operating system 
are a kernel 1 1 , a loader program 1 2, and a loader pro- 
gram 22. 

The kernel 11 is a software module for executing 
the fundamental processing for the intelligent functions 
of the terminal device 10. This processing includes 
checking each software module after the terminal de- 
vice is switched on and starting a loader program. 

The loader program 12 is a master loader program 
stored in bank 1. In the present embodiment the loader 
program is used by the processor 6 for starting the ap- 
plication programs stored in the software module group 
storage unit 5 and for upgrading the software modules 
by download. 

The main download processing of the leader pro- 
gram 12 includes error detection and defragmentation. 

Error detection is a process of detecting garbled 
bank data in the private stream using the CRC or the 
like. Bank data which is judged to be normal as a result 
of the error detection is stored into a target bank (a bank 
into which the bank data is to be stored).. On the other 
hand, for bank data in which an error is detected, the 
processor 6 retries to receive the bank data from the 
broadcast station according to the master loader pro- 
gram 12. If the digital satellite broadcast station trans- 
mits the same private stream in a predetermined cycle, 
the processor 6 receives the private stream and per- 
forms the error detection again. 

Defragmentation is composed of the following two 
processes. First, when new software modules that are 
larger than the corresponding old software modules 
cannot be contained within an area occupied by the old 
software modules, other software modules which have 
been written in the memory are relocated so as to gen- 



erate a free area sufficient for writing the new software 
modules Second, when a free area is left after writing 
new software modules that are smaller than the corre- 
sponding old software modules into an area occupied 
5 by the old software modules, other software modules 
which have been written in the memory are relocated so 
as to eliminate the free area. 

The above processes have to be performed each 
time the terminal device 10 receives bank data. Accord- 
10 ingly, the download processing of the master loader pro- 
gram 1 2 usually requires a considerable amount of time. 

The backup loader program 22 is stored in a differ- 
ent bank (bank 2) from the master loader program 12 
and has the same download processing as the master 
is loader program 12. 

The processor 6 includes a program counter for 
specifying a read address in the software module group 
storage unit 5, a reading circuit for reading a machine 
instruction of a software module which is located at the 
?o read address, a decoder for decoding the read instruc- 
tion, and an arithmetic unit for performing an arithmetic 
operation according to the decoded instruction. The 
processor 6 accesses the download RAM 4 and the boot 
ROM 7 which are connected to a first bus 19 and exe- 
25 cutes the application programs in the software module 
group storage unit 5. 

The boot ROM 7 stores a boot program which is 
used by the processor 6 to perform a bootstrap when 
the terminal device 10 is switched on. 
?o A MMU (Memory Management Unit) 8 associates 
each actual address in the EEPROMs 51-54 with a re- 
spective logical address. When the processor 6 outputs 
a read address to the first bus 1 9, the MMU 8 interprets 
the read address as a logical address and outputs an 
'5 actual address corresponding to the logical address to 
the second bus 9. The MMU 8 is located between the 
first bus 1 9 and the software module group storage unit 
5 so that the EEPROMs 51 -54 are given a linear address 
space which is accessible by the processor 6. 
o Figs. 8 and 9 are flowcharts showing the processing 
of the kernel 11 after the terminal device 10 is switched 
on and the download processing of the loader program. 

When the terminal device 1 0 is switched on, the CS 
tuner 1 demodulates a 7t/4QPSK-modulated digital sat- 
5 ellite broadcast wave and outputs the resulting transport 
packet that conforms to MPEG2 Standard to the TS de- 
coder 2. The TS decoder 2 separates the received trans- 
port packet into a video stream, an audio stream, a PCR 
stream, and a private stream. The AV decoder 3 de- 
' codes the video and audio streams into image signals 
using the PCR stream and outputs the image signals to 
the TV receiver. As a result, users can enjoy a variety 
of TV programs such as movies, dramas, sports, and 
educational programs displayed on the TV receiver. 
> Meanwhile, the program counter in the processor 6 
is set at a first address of the boot ROM 7. The processor 
performs the bootstrap according to the boot program 
stored in the boot ROM 7. The program counter in the 
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processor "6 is then set at a first step of the kernel 
processing shown in Fig. 8. 

First, the processor 6 checks a CRC of each soft- 
ware module stored in banks 1-4 (Step S1 ). If an error 
is detected, appropriate error handling such as a retry 
of reading software modules is conducted (Step S2). 
When no error is detected, the processor 6 judges 
whether there are a plurality of loader programs (Step 
S3). If there is only one loader program, the processor 
6 starts the loader program (Step S5). If, on the other 
hand, there are two or more loader programs, such as 
the loader programs 12 and 22, the processor 6 refers 
to version information of each loader program and starts 
the newest loader program (Step S4). 

For the example in Fig. 5A, when the master loader 
program 12 is newer than the backup loader program 
22, the program counter of the processor 6 is set at a 
first address of the master loader program 12, and the 
processor 6 branches from the kernel 1 1 to the master 
loader program 12. 

The processor 6 starts a variety of application pro- 
grams by sequentially executing the master loader pro- 
gram 12. Meanwhile, the processor 6 starts the down- 
load processing shown in Fig. 9. 

The processor 6 judges whether a private stream 
has been newly stored into the download RAM 4 (Step 
S11). Step S11 is repeated until a private stream is 
stored into the download RAM 4. When bank data for 
bank n is stored into the download RAM 4 as shown in 
Fig. 12A (a crosshatched area in the figure), the proc- 
essor 6 checks a CRC of the private stream (Step S1 2). 
If an error is detected, the processing returns to Step 
S11. If no error is detected, the processor 6 judges 
whether new bank data (hereinafter the term "new 8 
means new to the terminal device 10, which is to say, 
the downloaded version has more recent version infor- 
mation than the version in the software module group 
storage unit 5) is included in the private stream by re- 
ferring to version information in a program header of the 
private stream (Step S13). 

On judging that the new bank data is included, the 
processor 6 detects a target bank into which the new 
bank data is to be stored by referring to a bank number 
in the program header of the private stream (Step S1 4). 
On detecting the target bank, the processor 6 recogniz- 
es a bank address in which the activated loader program 
is stored (Step S15). The processor 6 then judges 
whether the target bank is the same as the bank which 
stores the activated loader program (Step S16). 

When they are not the same, as shown in Fig. 1 2A 
where the master loader program 12 is stored in bank 
1 while the target bank of the new bank data is bank n, 
the processing proceeds to Step S6. The processor 6 
divides the new bank data into a plurality of software 
modules (Step S6) and writes them into bank n (Step 
S8). 

In Step S8, the new software modules are simply 
written into the bank without conducting error detection 



and defragmentatton, so that the write processing re- 
quires only a short period of time. Since there is a low 
probability of the power being cut off during such a short 
period, the upgrade of the bank data stored in bank n is 

5 successfully completed as shown in Fig. 12B. 

After upgrading the bank data of bank n, another 
private stream including bank data for bank 1 is stored 
into the download RAM 4 as shown in Fig. 13A. The 
processor 6 chooses "Yes" in Step S1 1 and proceeds to 

10 step S1 2. The processor 6 checks a CRC of the private 
stream (Step S12), judges whether the private stream 
includes the new bank data (Step S1 3), and detects that 
a target bank of the bank data is bank 1 by referring to 
a bank number in the program header of the private 

is stream (Step S14), before detecting the bank which 
stores the activated loader program (Step S15). 

The processor 6 judges whether the target bank is 
the same as the bank which stores the activated loader 
program (Step S16). Here, both the target bank and the 

20 bank which stores the activated loader program are 
bank 1 . Accordingly, the processor 6 chooses "Yes" in 
Step S16 and branches to the kernel 11 in order to alter 
the version information of the backup loader program 
22 (Step S17). After altering a date shown in version 

2S information of the backup loader program 22 stored in 
bank 2 to a more recent date according to the kernel 1 1 , 
the processor 6 returns to the loader program process- 
ing. The processor 6 changes a CRC of the backup load- 
er program 22 in response to the altered version ihfor- 

30 mation (Step S18). Then the program counter of the 
processor 6 is reset (Step SI 9). 

As a result of the above processing, a loader pro- 
grarri to be started by the processor 6 next time be- 
comes the backup loader program 22 stored in bank 2 

35 and hot the -master loader program 12. That is to say, 
when the terminal device 1 0 is started after resetting the 
program counter of the processor 6, the loader program 
with the newest version information is selected in the 
kernel processing as shown in Fig. 1 3B (see Step S4 in 

40 Fig. 8). 

* The following is an explanation of the processing 
when the processor 6 executes the backup loader pro- 
gram 22. The program counter of the processor 6 is re- 
set at the first address of the boot ROM 7. After perform- 

45 ing the bootstrap according to the boot program stored 
in the boot ROM 7, the processor 6 checks a CRC of 
each software module in banks 1 -4 (Step S1 ). When no 
error is detected, the processor 6 judges whether there 
are a plurality of loader programs (Step S3) and starts 

so a loader program with the newest version information 
(Step S4). Here, when comparing the version informa- 
tion of the loader programs 1 2 and 22, the backup loader 
program 22 has the newer version information as a re- 
sult of the alteration, so that the program counter of the 

55 processor 6 is set at a first address of the backup loader 
program 22. The processor 6 then switches the process- 
ing from the kernel 1 1 to the backup loader program 22. 
The processor 6 starts a variety of application pro- 



7 



BNSDOCID: <EP 0887729A2_I_> 



13 



EP 0 887 729 A2 



14 



grams by sequentially executing the backup loader pro- 
gram 22. Meanwhile, the processor 6 starts the down- 
load processing shown in Fig. 9. 

The processor 6 judges whether a private stream is 
newly stored into the down bad RAM 4 (Step S11 ). Here, 
the bank data for bank 1 has already been stored in the 
download RAM 4 as shown in Fig. 1 3B (a crosshatched 
area in the figure). Accordingly, the processor 6 checks 
a CRC of the private stream (Step S1 2), judges whether 
the new bank data is included in the private stream (Step 
S13) : and detects a target bank of the new bank data 
by referring to a bank number in the program header of 
the private stream (Step S14). On detecting the target 
bank, the processor 6 recognizes a bank in which the 
activated loader program is stored (Step S1 5). The proc- 
essor 6 then judges whether the target bank is the same 
as the bank which stores the activated loader program 
(Step S16). 

Here, since the activated loader program is the 
backup loader program 22 stored in bank 2 while the 
target bank is bank 1 , the processor 6 proceeds to Step 
S6. The processor 6 divides the new bank data into a 
plurality of software modules (Step S6) and writes them 
into bank 1 (Step S8). As a result, the bank data stored 
in bank 1 is upgraded as shown in Fig. 1 3C. The master 
loader program 12 included in the bank data in bank 1 
is also upgraded. 

In the present embodiment, software modules are 
stored and upgraded in each of a plurality of banks, so 
that a RAM with a memory size same as one bank is 
sufficient as a buffer for downloaded bank data. It is pos- 
sible to reduce a scale of hardware that can withstand 
errors that occur during software upgrades. As a result, 
advanced software can be installed in the terminal de- 
vice without increasing the production cost. .. . .. 

Also, by storing a master loader program and a 
backup loader program in different banks, it is possible 
to upgrade one loader program while executing the oth- 
er loader program. As a result, bug fixing and specifica- 
tion changes for the loader program can be conducted 
easily by upgrading the loader program in the above way 
without exchanging ROMs that incurs a great labor cost 
to the broadcast company. 

It is not desirable to frequently upgrade bank data 
of the bank which stores the master loader program, 
since the upgrade of the master loader program requires 
the extensive processing of starting the backup loader 
program stored in a different bank. Accordingly, it is pref- 
erable to store software modules which have to be fre- 
quently upgraded in banks other than the bank which 
stores the master loader program. In particular, software 
modules relating to MPEG stream decoding, and soft- 
ware modules for displaying weekly and monthly electric 
program guides need to be frequently upgraded and so 
are preferably stored in banks other than the bank stor- 
ing the master loader program. 

In the present embodiment, a target bank of each 
software module is determined by a bank number in a 



module header of the software module, while a target 
bank may be changed based on upgrade frequency of 
each software module. 

5 Second Embodiment 

In the second embodiment, a loader bank (a bank 
which stores the master loader program) is upgraded 
without using a backup loader program so as to improve 
10 the efficiency of the ROM use. By using only a master 
loader program, more software modules can be stored 
in an area which was occupied by the backup loader 
program in the first embodiment. 

There is one prerequisite for upgrading the loader 
*5 program in the second embodiment. The prerequisite is 
that banks other than the loader bank should include 
one recoverable bank. A recoverable bank means a 
bank that stores data which can be recovered even if 
damaged, either because bank data of the recoverable 
20 bank is repeatedly transmitted from the host station at 
regular intervals or because the terminal device in- 
structs the host station to transmit the bank data by 
sending a request signal. 

Fig. 10 is a flowchart showing the processing of the 
25 loader program in the second embodiment. The terminal 
device 10 of the second embodiment is constructed in 
such a way as to upgrade the master loader program 
without using a backup loader program. The following 
is an explanation of the loader program upgrade 
30 processing with reference to Figs. 10 and 14A-14D. Fig. 
14A shows an initial state of the processing. Here, the 
loader bank is bank 1, while the recoverable bank is 
bank 2. The new bank data for bank 1 is stored in the 
download RAM 4. 
35 First, the processor 6 performs the same process- 
ing as Steps S11-S14 in Fig. 9. In Step S11, the proc- 
essor 6 judges whether a private stream is newly stored 
into the download RAM 4. If so, the processor 6 checks 
a CRC of the private stream (Step S12), judges whether 
40 the private stream includes new bank data (Step S1 3), 
and detects a target bank of the new bank data (Step 
S14). Next, the processor 6 judges whether the target 
bank of the new bank data is the loader bank (Step S22). 
When the target bank is the loader bank, the proe- 
ms essor 6 writes the new bank data not into bank 1 which 
is the loader bank but into bank 2 which is the recover- 
able bank (Step S23). Here, the processor 6 performs 
the same write processing as Steps S6-S8 in Fig. 9. The 
processor 6 divides the bank data into a plurality of soft- 
50 ware modules (Step S6) and writes them into the recov- 
erable bank (Step S8). 

On writing the bank data into the recoverable bank, 
the processor 6 alters the loader bank to the old loader 
bank, and the recoverable bank to the new loader bank 
55 (Step S24). 

Fig. 14B shows a state after completing Step S24 
in the loader program upgrade processing. In the figure, 
the old loader bank data and the new loader bank data 



BNSOCCID: <EP 0S87729A2 I 



15 



EP 0 887 729 A2 



16 



are respectively stored in the banks 1 and 2. Then the 
program counter of the processor 6 is reset (Step S25). 

As a result of the above processing, a loader pro- 
gram to be started by the processor 6 next time be- 
comes the new loader program stored in the new loader 
bank. That is to say, when the terminal device 10 is re- 
started after resetting the program counter of the proc- 
essor 6, the new loader program in the new loader bank 
is selected in the kernel processing as shown in Fig. 1 4B 
(see Step S4 in Fig. 8). 

On starting the new loader program in the new load- 
er bank, the processor 6 performs the same processing 
as Steps S11-S14 in Fig. 9. In Step S11, the processor 
6 judges whether a private stream is newly stored into 
the download RAM 4. 

Here, a private stream including new bank data for 
bank 2 which was the recoverable bank is stored into 
the download RAM 4 as shown in Fig. 14C as a result 
of periodical transmission of the bank data from the host 
station. The processor 6 checks a CRC of the private 
stream (Step S12), judges whether the new bank data 
is included in the private stream (Step S 1 3), and detects 
a target bank of the new bank data (Step S14). The proc- 
essor 6 then judges whether the target bank is the 
former loader bank (Step S22). Since the target bank is 
the recoverable bank, the processor 6 chooses "No" in 
Step S22 and proceeds to Step S26. 

The processor 6 judges whether the target bank is 
the former recoverable bank (Step S26). If so, the proc- 
essor 6 judges whether the recoverable bank has been 
altered to the new loader bank (Step S27). If the recov- 
erable bank has not been altered, the processor 6 writes 
the new bank data into the recoverable bank (Step S29) 
and completes the upgrade processing. 

If the recoverable bank (bank 2) has been altered 
to the new loader bank as in the present example shown 
in Fig. 14B, the processor 6 chooses "Yes" in Step S27 
and proceeds to Step S28. 

The processor 6 alters bank 1 which has been al- 
tered to the old loader bank in Step S24 to a recoverable 
bank (Step S28). Asa result, bank 1 is the recoverable 
bank and bank 2 is the loader bank after completing 
Step S28. 

The processor 6 then writes the new bank data 
stored in the download RAM 4 into bank 1 which is the 
new recoverable bank (Step S29). Fig. 14D shows a fi- 
nal state of the upgrade processing shown in Fig. 10. 
As shown in the figure, banks 1 and 2 are both upgraded 
while being respectively altered so as to become the re- 
coverable bank and the loader bank. 

In the present embodiment, when new bank data 
for the loader bank is transmitted from the host station, 
the new bank data is written into the recoverable bank 
and the loader bank is changed to a new recoverable 
bank. Thus, the loader program can be upgraded using 
only the master loader program. Accordingly, more soft- 
ware modules can be stored in the terminal device 10 
in place of the backup loader program. 



Third Embodiment 

In the third embodiment, the upgrade is performed 
in units of software modules. Fig. 6 shows the construc- 
s tion of a private stream in the third embodiment. The 
difference with the first embodiment lies in that n soft- 
ware modules for different banks are multiplexed in one 
private stream. 

Fig. 7 shows the construction of the terminal device 
10 10 of the third embodiment. The difference with the ter- 
minal device 1 0 shown in Fig. 2 lies in that the download 
RAM 4 is replaced with a new software module RAM 1 3 
and a bank data copy RAM 1 4. 

The new software module RAM 1 3 stores a private 
15 stream into which software modules have been multi- 
plexed, the private stream having been separated by the 
TS decoder 2. 

The bank data copy RAM 14 is used to store bank 
data when replacing software modules. In the software 
20 module replacement, when a new software module is 
stored into the new software module RAM 1 3, bank data 
which includes the old software module corresponding 
to the new software module is written from a bank into 
the bank data copy RAM 14 so that the old software 
25 moduie in the copied data in the bank data copy RAM 
14 can be replaced with the new software module. This 
revised bank data is then overwritten into the original 
bank. 

Fig. 11 is a flowchart showing the loader program 

30 processing in units of software modules. Figs. 15A-15D 
and 16A-16C show states of the software module up- 
grade processing. 

Fig. 15A shows an initial state of the processing. In 
the figure, software modules A11.old to A16.old are 

35 stored in bank 1, and software modules B11.old to 
B16 bid are stored in bank 2. A title "old" indicates that 
the software module is the old version. Two software 
modules A13.new and B15.new are stored in the new 
software module RAM 1 3. These are new software mod- 

40' ules that were included in a private stream separated by 
the TS decoder 2. 

When the terminal device 10 is switched on, the 
processor 6 starts to monitor whether a private stream 
has been newly stored into the new software module 

45 ram 13 (Step S31 in Fig. 11). When a private stream 
has been stored, the processor 6 checks a CRC of the 
private stream (Step S32). If no error is detected, the 
processor 6 obtains n new software modules included 
in the private stream (Step S33) and sets an initial value 

so of a variable i (Step S34). The variable i is used for spec- 
ifying each of the n software modules stored in the new 
software module RAM 1 3. By setting the variable i at 1 , 
the first software module among the n software modules 
is set as a processing object. 

55 The processor 6 obtains version information in a 
module header of the B i B th software module (Step 335) 
and detects a bank number k in the version information 
(Step S36). 
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Since the first software module in the new software 
module RAM 1 3 is new software module A1 3 new with 
the version information specifying bank number 1 , bank 
1 is recognized as a target bank. The processor 6 then 
writes bank data stored in the bank k (bank 1) into the 
bank data copy RAM 14 (Step S37). Fig. 15B shows a 
first intermediate state after completing Step S37. In the 
figure, software modules A11.old to Al6.old stored in 
bank 1 have been written in the bank data copy RAM 1 4. 

The processor 6 then replaces a corresponding old 
software module in the bank data copy RAM 14 with the 
Vth (first) software module stored in the new software 
module RAM 13 (Step S38). 

Fig. 15C shows a second intermediate state after 
completing Step S38. In the figure, software module 
A13.otd is replaced with software module A13.new in 
the bank data copy RAM 14. Thus, software module 
A13.old in bank 1 is upgraded. 

The processor 6 writes the revised bank data from 
the bank data copy RAM 14 back into the bank k (bank 

1) (StepS39). 

Fig. 1 5D shows a third intermediate state after com- 
pleting Step S39. In the figure, the bank data which in- 
cludes new software module A1 3.new is stored in bank 
1 . On completing the upgrade processing for the first 
software module, the processor 6 judges whether i=n 
(Step S40). When h*n, the processor 6 increments the 
variable i by 1 (Step S41) and returns to Step S35. 

The processor 6 obtains version information of the 
second software module stored in the new software 
module RAM 1 3 (Step S35) and detects a bank number 
k in the version information (Step S36). 

Here, the second software module is software mod- 
ule B1 5.new with a bank number specifying bank 2. Ac- 
cordingly, the processor 6 recognizes bank 2 as a target 
bank. The processor 6 then writes bank data stored in 
the bank k (bank 2) into the. bank data copy RAM 14 
(Step S37). Fig. 16A shows a fourth intermediate state 
after completing Step S37. As shown in the figure, soft- 
ware modules Btl.old to B16.old stored in, bank 2 are 
written in the bank data copy RAM 14. 

The processor 6 then replaces a corresponding old 
software module in the bank data copy RAM 14 with the 
Vth (second) soltware module stored in the new soft- 
ware module RAM 13 (Step S38). 

Fig. 1 6B shows a fifth intermediate state after com- 
pleting Step S38. As shown in the figure, software mod- 
ule B15.old is replaced with new software module 
B1 S.new in the bank data copy RAM 14. Thus, software 
module B15.old in bank 2 is upgraded. 

The processor 6 writes the revised bank data from 
the bank data copy RAM 14 back into the bank k (bank 

2) (Step S39). 

Fig. 1 6C shows a final state after completing Step 
S39. As shown in the figure, the bank data which in- 
cludes new software module B1 S.new is stored in bank 
2. 

On completing the upgrade processing for the sec- 



ond software module, the processor 6 judges whether 
i=n (Step S40). Here, since i=n=2, the upgrade process- 
ing for all new software modules in the new software 
module RAM 13 is completed. 

5 in the third embodiment, the terminal device 10 re- 

ceives the new version of software modules to be up- 
graded from the host station and performs the upgrade 
processing in units of software modules. When com- 
pared with the first and second embodiments where the 

10 upgrade processing is performed in bank units, the up- 
grade can be completed in a shorter processing time. 

Fourth Embodiment 

is in the fourth embodiment, it is possible to perform 
remote upgrades of software in a terminal device which 
does not have the upgrade functioning, by loading a 
smart card 15 into the terminal device. Fig. 17 shows 
the construction of the terminal device 10 of the fourth 

20 embodiment. When compared with the terminal device 
10 shown in Fig. 2. a software module group storage 
ROM 1 6 and a card slot 1 7 are connected to the second 
bus 9 in place of the software module group storage unit 
5, and a boot ROM 18 is connected to the first bus 19 

2S in place of the boot ROM 7. 

The smart card 1 5 is a memory card containing the 
EEPROMs 51-54 which were included in the terminal 
device 1 0 of the first to third embodiments. Its connector, 
package, and electric characteristics are designed in ac- 

30 cordance with, for example, PCMCIA (Personal Com- 
puter Memory Card International Association) Stand- 
ard. 

The software module group storage ROM 16 stores 
the same software modules as the software module 
35 group storage unit 5 of the first to third embodiments, so 
that processing other than the remote download can be 
performed with the software module group storage 
ROM 16. 

The card slot 1 7 is used for loading the smart card 

40 15 into the terminal device 10. Once the smart card 15 
is loaded into the terminal device 10, the EEPROMs 
51 -54 in the smart card 1 5 are connected to the second 
bus 9 and become accessible by the processor 6. 

The boot ROM 18 is used for checking a loading 

45 state of the smart card 15 in the card slot 17 when the 
terminal device 10 is switched on. When the smart card 
15 is not loaded in the card slot 17, the processor 6 per- 
forms a bootstrap for starting each software module 
stored in the software module group storage ROM 16. 

so When, on the other hand, the smart card 1 5 is loaded 
in the card slot 1 7, the processor 6 performs a bootstrap 
for starting each software module stored in the EEP- 
ROMs 51 -54 in the smart card 1 5. 

With the present embodiment, if a terminal device 

55 that was manufactured and sold at a time when remote 
upgrades of software were not possible has a card slot 
17, then it is possible to perform remote upgrades of 
software in the same way as the first embodiment of the 
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present invention by merely attaching the smart card 1 5. 
Fifth Embodiment 

In the fifth embodiment, a smart card 15 is loaded $ 
into a terminal device in order to upgrade a loader pro- 
gram. Fig. 18 shows the construction of a terminal de- 
vice 10 of the fifth embodiment. When compared with 
the terminal device 10 in Fig. 2, a card slot 17 is con- 
nected to the second bus 9 in place of the EEPROM 51, 10 
and a boot ROM 18 is connected to the first bus 19 in 
place of the boot ROM 7. 

The smart card 15 in the present embodiment con- 
tains the EEPROM 51 which was connected to the sec- 
ond bus 9 in the first to third embodiments. is 

The EEPROM 52 stores a loader program and a 
kernel, so that the processing other than the remote 
download can be performed with the EEPROMs 52-54. 

The boot ROM 18 is used for checking a loading 
state of the smart card 15 in the card slot 17 when the 20 
terminal device 10 is switched on. When the smart card 
1 5 is not loaded in the card slot 1 7, the processor 6 per- 
forms a bootstrap for starting the loader program and 
the kernel stored in the EEPROM 52. When, on the other 
hand, the smart card 1 5 is loaded in the card slot 1 7, the 2s 
processor 6 performs a bootstrap for starting a loader 
program and a kernel stored in the EEPROM 51 in the 
smart card 15. 

The loader program can be upgraded in the same 
way as the first embodiment by storing the loader pro- 30 
gram and the kernel both in the EEPROMs 51 and 52. 
That is to say, when new software modules for bank 1 
in the EEPROM 51 are stored into the download RAM 
4, the new software modules can be written into the 
EEPROM 51 by switching the activated program from 
the loader program in the EEPROM 51 to the loader pro- 
gram in the EEPROM 52. 

With the present embodiment, if a terminal device 
that was manufactured and sold at a time when remote 
upgrades of software were not possible has a card slot 40 
17, then it is possible to perform remote upgrades of 
software in the same way as the first embodiment of the 
present invention by merely attaching the smart card 1 5. 

While a smart card 15 that conforms to PCMCIA 
Standard is used in the terminal device 1 0 of the fourth 45 
and fifth embodiments, a card which conforms to other 
standards may also be used. Also, an other erasable 
storage medium, such as a phase change-type optical 
DVD-RAM, may be used instead of the smart card 15. 
In such a case, the terminal device 10 is equipped with so 
a disc driver instead of the card slot 1 7 in order to load 
the DVD-RAM which stores software modules. 

While the above first to fifth embodiments have 
been explained as examples of achieving the effects of 
the invention, the present invention is not limited to such ss 
but can be applied to any system for ensuring that acti- 
vation will be possible for a terminal device. For in- 
stance, the following modifications are possible. 



(a) While the upgrade processing is started once 
the terminal device receives new bank data in the 
above embodiments, the new bank data may be 
stored in a RAM until the user touches an end button 
or a power button, with the upgrade processing 
starting thereafter. 

(b) Other constructions may be used for the pro- 
gram header and the module header. For example, 
a program name, a data size, a storage address in 
a bank, and version information may be included in 
a header of bank data. 

(c) While a target bank is detected by the processor 
6 referring to a bank number written in a program 
or module header of each private stream or each 
software moduie according to a loader program in 
the above embodiments, other methods may be 
used instead. For example, a target bank may be 
determined according to information such as the 
program name and the version information. 

(d) The present invention is not limited to a digital 
satellite broadcast service but can also be applied 
to other broadcast services, such as the digital 
CATV. 

Although the present invention has been fully de- 
scribed by way of examples with reference to the ac- 
companying drawings, it is to be noted that various 
changes and modifications will be apparent to those 
skilled in the art. Therefore, unless such changes and 
modifications depart from the scope of the present in- 
vention, they should be construed as being included 
therein. 



35 Claims 



1 . A terminal device, comprising: 

a first memory having n areas which are each 
given a unique bank address, n being an inte- 
ger that is no less than 2, 
wherein each area is composed of an occupied 
area storing at least one software module and 
a free area which is used when a data size of 
the software modules increases as a result of 
upgrading the software modules; 
a second memory having a same memory size 
as each area; 

reception means for receiving transmission da- 
ta from a host station, 

wherein the transmission data includes a con- 
tent part and a header part, 
wherein the content part includes at least one 
new software module corresponding to at least 
one software module stored in any of the n ar- 
eas, and the header part includes a target bank 
address specifying an area into which the new 
software modules are to be stored, 



BNSDOCID: <EP 0887729A2J_> 



11 



21 



EP 0 887 729 A2 



22 



wherein each new software module is new to 
the terminal device, that is, each new software 
module has more recent version information 
than a corresponding software module stored 
in any of the n areas; 

separation means for separating the header 
part from the transmission data and storing the 
content part which includes the new software 
modules into the second memory; 
detection means for detecting the target bank 
address from the header part; and 
write means for writing the new software mod- 
ules stored in the second memory into the area 
specified by the detected target bank address. 

2. The terminal device ot Claim 1 , 

wherein, among the n areas, a first area and a 
second area respectively store a master loader 
program and a backup loader program, and 
wherein the write means includes: 
a first write control unit for writing, when the de- 
tected target bank address specifies an area 
other than the first area, the new software mod- 
ules stored in the second memory into the area 
other than the first area according to the master 
loader program in the first area; and 
a second write control unit for writing, when the 
detected target bank address specifies the first 
area, the new software modules stored in the 
second memory into the first area according to 
the backup loader program in the second area. 

3. The terminal device ot Claim 2, - - 

wherein software modules stored in the first 
area are less frequently upgraded than software 
modules stored in areas other than the first area. 

4. . The terminal device of Claim 1 , wherein a first area, 

among the n areas, stores a master loader program, 

wherein the write means includes: 
a first write control unit for writing, when the de- 
tected target bank address specifies an area 
other than the first area, the new software mod- 
ules stored in the second memory into the area 
other than the first area according to the master 
loader program in the first area; 
a second write control unit for writing, when the 
detected target bank address specifies the first 
area, the new software modules stored in the 
second memory into a second area which is dif- 
ferent from the first area according to the mas- 
ter loader program in the first area; 
a monitor unit for monitoring, afterthe new soft- 
ware modules are written into the second area, 
whether the second memory stores at least one 
new software module corresponding to at least 



one software module which was previously 
stored in the second area; and 
a third write control unit for writing, when the 
second memory stores the new software mod- 
5 ules corresponding to the software modules 

which were previously stored in the second ar- 
ea, the new software modules stored in the sec- 
ond memory into the first area according to a 
new master loader program included in the new 
w software modules written in the second area. 

5. The terminal device of Claim 4, 

wherein software modules stored in an area 
which stores the master loader program are less 
is frequently upgraded than software modules stored 
in areas other than the area which stores the master 
loader program. 

6. The terminal device of Claim 1 , wherein the content 
20 part includes a plurality of new software modules, 

and the header part includes a plurality of target 
bank addresses which each specify an area into 
which each new software module in the content part 
is to be stored, 

25 wherein the terminal device further comprises 

a third memory having the same memory size 
as each area, and 
wherein the write means includes: 
a retrieval unit for retrieving one of the plurality 
of new software modules in the content part 
from the second memory; 
a first write control unit for writing all software 
rnodules stored in an area specified by a de- 
tected target bank address for the retrieved 
new software module into the third memory; 
a replacement unit for replacing a software 
module, out of the software modules stored in 
the third memory, which corresponds to the re- 
trieved new software module with the retrieved 
new software module; 

a second write control unit for writing the soft- 
ware modules after a replacement by the re- 
placement unit from the third memory into the 
area specified by the detected target bank ad- 
dress; and 

a retrieval control unit for having the retrieval 
unit retrieve another new software module, out 
of the plurality of new software modules, from 
the second memory after a write by the second 
write control unit. 

A download method applied to a loader program 
that is used in a terminal device, wherein the termi- 
nal device comprises: a memory having n areas that 
store a total of m software modules, wherein 
m^n^2, wherein a master loader program and a 
backup loader program are respectively stored in 
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two different areas; a reception unit for receiving 
transmission data which includes at least one new 
software module corresponding to at least one soft- 
ware module stored in any of the n areas; a buffer 
for storing the new software modules; and an exe- s 
cution unit for executing the master loader program 
when the reception unit has received the transmis- 
sion data, 

the download method comprising: 

10 

an identification step of identifying an area 
which stores the software modules correspond- 
ing to the new software modules stored in the 
buffer; 

a judgement step of judging whether the iden- is 
titied area is an area that stores a currently ex- 
ecuted loader program; 

a write step of writing the new software modules 
stored in the buffer into the identified area when 
the identified area is different from the area that 20 
stores the currently executed loader program; 
and 

a start step of starting the backup loader pro- 
gram when the identified area is the area that 
stores the currently executed loader program. 2s 

8. The download method of Claim 7, wherein the 
transmission data includes target bank address in- 
formation that specifies an area into which the new ! 
software modules are to be stored, 30 - 

wherein the identification step includes a first 
recognition substep of recognizing the area 
specified by the target bank address informa- 
tion when the new software modules are stored 35 
into the buffer, and 

wherein the judgement step includes: 
a second recognition substep of recognizing 
the area which stores the currently executed 
loader program; and 40 
a judgement substep of judging whether the ar- 
ea recognized in the first recognition substep is 
the area recognized in the second recognition 
substep. 

45 

9. A download method applied to a loader program 
that is used in a terminal device, wherein the termi- 
nal device comprises: a memory having n areas that 
store a total of m software modules, wherein 
m^n^2, wherein one of the n areas stores a master so 
loader program; a reception unit for receiving trans- 
mission data which includes at least one new soft- 
ware module corresponding to at least one software 
module stored in any of the n areas; a buffer for stor- 
ing the new software modules; and an execution ss 
unit for executing the master loader program when 

the reception unit has received the transmission da- 
ta, 



the download method comprising: 

an identification step of identifying an area 
which stores the software modules correspond- 
ing to the new software modules in the buffer; 
a first judgement step of judging whether the 
identified area is an area which stores a cur- 
rently executed master loader program; 
a first write step of writing the new software 
modules stored in the buffer into a new loader 
area when the identified area is the area which 
stores the currently executed master loader 
program, 

wherein the area which stores the currently ex- 
ecuted master loader program is an original 
loader area, 

wherein the new loader area is different from 
the original loader area; 

a start step of starting a new master loader pro- 
gram included in the new software modules 
written in the new loader area; 
a second judgement step of judging whether 
the buffer stores at least one new software 
module corresponding to at least one software 
module which was previously stored in the new 
loader area after the new master loader pro- 
gram' is started; and 

a second write step of writing, when the buffer 
stores the new software modules correspond- 
ing to the software modules which were previ- 
ously stored in the new loader area, the new 
software modules into the old loader area. 

10. A download method applied to a loader program 
that is used in a terminal device, wherein the termi- 
nal device comprises: a memory having n areas that 
store "a total of m software modules, wherein 
m^n^2, wherein a master loader program and a 
backup loader program are respectively stored in 
two different areas; a reception unit for receiving 
transmission data which includes at least one new 
software module which each correspond to a soft- 
ware module stored in any of the n areas; a first buff- 
er lor storing the new software modules; a second 
buffer capable of storing software modules stored 
in any of the n areas; and an execution unit for ex- 
ecuting the master loader program when the recep- 
tion unit has received the transmission data, 
the download method comprising; 

a retrieval step of retrieving one of the new soft- 
ware modules stored in the first buffer; 
an identification step of identifying an area 
which stores a software module corresponding 
to the retrieved new software module; 
a first write step of writing all software modules 
stored in the identified area into the second 
buffer; 
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a replacement step of replacing the software 
module, among the software modules in the 
second buffer, which corresponds to the re- 
trieved new software module with the retrieved 
new software module; 5 
a second write step of writing the software mod- 
ules after the replacement stepf rom the second 
buffer into the identified area; and 
a control step of retrieving an another new soft- 
ware module from the first buffer after the sec- 
ond write step. 

11. A storage medium storing a loader program that is 
used in a terminal device, wherein the terminal de- 
vice comprises: a memory having n areas that store 
a total of m software modules, wherein m^n^2, 
wherein a master loader program and a backup 
loader program are respectively stored in two differ- 
ent areas; a reception unit for receiving transmis- 
sion data which includes at least one new software 
module corresponding to at least one software 
module stored in any of the n areas; a buffer for stor- 
ing the new software modules; and an execution 
unit for executing the master loader program when 
the reception unit has received the transmission da- 
ta, 

the loader program comprising: 

an identification step of identifying an area 
which stores the software modules correspond- 
ing to the new software modules stored in the 
buffer 

a judgement step of judging whether the iden- 
tified area is an area that stores a currently ex- 
ecuted loader program; 
a write step of writing the new software modules 
stored in the buffer into the identified area when 
the identified area is different from the area that 
stores the currently executed loader program; 
and 

a start step of starting the backup loader pro- 
gram when the identified area is the area that 
stores the currently executed loader program. 

1 2. The storage medium of Claim 1 1 , wherein the trans- 
mission data includes target bank address informa- 
tion that specifies an area into which the new soft- 
ware modules are to be stored, 

wherein the identification step includes a first 
recognition substep of recognizing the area 
specified by the target bank address informa- 
tion when the new software modules are stored 
into the buffer, and 

wherein the judgement step includes: 
a second recognition substep of recognizing 
the area which stores the currently executed 
loader program; and 



a judgement substep of judging whether the ar- 
ea recognized in the first recognition substep is 
the area recognized in the second recognition 
substep. 

13. A storage medium storing a loader program that is 
used in a terminal device, wherein the terminal de- 
vice comprises: a memory having n areas that store 
a total of m software modules, wherein m^n^2, 
wherein one of the n areas stores a master loader 
program; a reception unit for receiving transmission 
data which includes at least one new software mod- 
ule corresponding to at least one soltware module 
stored in any of the n areas; a buffer for storing the 
new software modules; and an execution unit for ex- 
ecuting the master loader program when the recep- 
tion unit has received the transmission data, 
the loader program comprising: 
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15 



20 an identification step of identifying an area 

which stores the software modules correspond- 
ing to the new software modules in the buffer; 
a first judgement step of judging whether the 
identified area is an area which stores an cur- 
25 rently executed master loader program; 

a first, write step of writing the new software 
modules stored in the buffer into a new loader 
area when the identified area is the area which 
stores the currently executed master loader 
30 program, 

wherein the area which stores the currently ex- 
ecuted master loader program is an original 
loader area, 

wherein the new loader area is different from 
35 the original loader area; 

a start step of starting a new master loader pro- 
gram included in the new software modules 
written in the new loader area; 
a second judgement step of judging whether 
40 the buffer stores at least one new software 

module corresponding to at least one software 
module which was previously stored in the new 
loader area after the new master loader pro- 
gram is started; and 
45 a second write step of writing, when the buffer 

stores the new software modules correspond- 
ing to the software modules which were previ- 
ously stored in the new loader area, the new 
software modules into the old loader area. 

50 

14. A storage medium storing a loader program that is 
used in a terminal device, wherein the terminal de- 
vice comprises: a memory having n areas that store 
a total of m software modules, wherein m^n^2, 
55 wherein a master loader program and a backup 
loader program are respectively stored in two differ- 
ent areas; a reception unit for receiving transmis- 
sion data which includes at least one new software 
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mociuie which each correspond to a software mod- 
ule stored in any of the n areas; a first buffer for stor- 
ing the new software modules; a second buffer ca- 
pable of storing software modules stored in any of 
the n areas; and an execution unit for executing the $ 
master loader program when the reception unit has 
received the transmission data, 

the loader program comprising: 

a retrieval step of retrieving one of the new soft- 10 

ware modules stored in the first buffer; 

an identification step of identifying an area 

which stores a software module corresponding 

to the retrieved new software module; 

a first write step of writing all software modules is 

stored in the identified area into the second 

buffer; 

a replacement step of replacing the software 
module, among the software modules in the 
second buffer, which corresponds to the re- 20 
trieved new software module with the retrieved 
new software module; 

a second write step of writing the software mod- 
ules after the replacement step from the second 
buffer into the identified area; and 2S 
a control step of retrieving an another new soft- 
ware module from the first buffer after the sec- 
ond write step. 

30 
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